React Server Component
빌드타임에 빌드 머신에서 실행되거나, 런타임에 서버에서 실행되는 컴포넌트. 2020년에 처음 제안됨.
서버 컴포넌트의 장점
- 서버에서만 실행되기 때문에 번들 크기에 영향을 주지 않음
- 파일 시스템, DB 등 서버측 리소스에 직접 접근 가능 (따라서 네트워크 round-trip에 따르는 지연 제거)
- 클라이언트 컴포넌트와 혼용 가능
- 어떤 클라이언트 컴포넌트를 사용할지 서버 컴포넌트가 동적으로 정할 수 있으며 이에 따라 클라이언트로 전송되는 코드의 양을 줄일 수 있음
- 서버 컴포넌트가 리로드될 때 클라이언트 상태(state, focus, animation 등)가 보존됨
- 점진적 렌더링 및 스트리밍을 지원
- 서버와 클라이언트에서 동일 코드를 공유할 수 있음. 클라이언트 컴포넌트의 제약과 서버 컴포넌트의 제약을 모두 준수해야 하므로 제약이 많지만 여전히 유용.
서버 컴포넌트의 제약
useState(),useReduce()등 상태(state) 사용 불가useEffect(),useLayoutEffect()등 라이프사이클 이펙트 사용 불가- DOM API 등 브라우저 전용 API 사용 불가 (polyfill을 하지 않는 한)
- 상태, 이펙트, 브라우저 전용 API 등에 의존하는 커스텀 훅 사용 불가
공용 컴포넌트
원칙적으로 클라이언트 컴포넌트의 제약(예: 서버 측 리소스 직접 접근 불가)과 서버 컴포넌트의 제약(위 “서버 컴포넌트의 제약” 참고)을 모두 준수하면 클라이언트와 서버 모두에서 실행되는 공용 컴포넌트를 만들 수 있음.
예: 동일한 “본문 렌더링” 컴포넌트를 관리자 페이지에서는 “편집 미리보기” 용으로 클라이언트 컴포넌트로 쓰고, 사용자 페이지에서는 서버 컴포넌트로 활용. 클라이언트 컴포넌트로 쓰는 경우엔 마크다운 렌더링 라이브러리를 전송할 필요가 없음.
SSR과의 차이
SSR은 클라이언트 컴포넌트를 서버측에서 렌더링하여 전송하는 기술이며 클라이언트에 컴포넌트 관련 코드가 전송되어야 하고 하이드레이트 과정을 필요로 함. RSC는 서버에서만 실행.
RSC와 SSR을 동시에 쓸 수 있음. RSC를 렌더링하는 과정에서 자식 컴포넌트(클라이언트 컴포넌트)를 SSR 방식으로 렌더링하여 클라이언트로 전송한 후 자식 컴포넌트만 하이드레이트하는 방식.
컴포넌트에서 DB에 직접 접근하는 게 좋은 설계인가?
FAQ에 따르면1 그렇지 않음. (코드의) 스케일이 작을 땐 직접 접근하고 스케일이 커지면 별도의 레이어를 분리하는 등 상황에 따른 설계를 하길 장려.
역사
- 2020-12-21 - Introducing Zero-Bundle-Size React Server Components – React
- RSC를 소개하는 글과 영상. 현재 구현과 차이가 있으나 주요 개념은 유지되고 있음
- 원래는
.server.js,.client.js등 파일 이름으로 구분했었는데 현재(2024년 기준)는use client디렉티브로 구분. - 위 소개와 달리 현재(2024년 기준)는
async,await을 지원.